Could you also locally run a check with --prefer-oldest at least on our oldest supported GHC, to see that the older plugins also still allow the changed code to type-check?

Could you also locally run a check with --prefer-oldest at least on our oldest supported GHC, to see that the older plugins also still allow the changed code to type-check?

Every build is currently failing due to warnings caused by clash-lang/ghc-typelits-natnormalise#105 (comment). I created another branch for just checking the changes to Clash.Sized.Vector: #3062.

I’m adding some features and fixes in clash-lang/ghc-typelits-natnormalise#110 which will hopefully only require haddock/doctest changes w.r.t. error messages for clash-prelude.

With the changes in clash-lang/ghc-typelits-natnormalise#110, the following is all that's needed to compile clash-prelude warning-free and pass the unit-tests and doctests: 9b4ca8a

[...] all that's needed to compile clash-prelude warning-free and pass the unit-tests and doctests: 9b4ca8a

I note you don't increase the lower bounds on the dependencies. So does it work with the whole range of versions in the interval then? I'm having trouble understanding how you fix a compilation error by merely allowing more versions of a dependency to be used...

[edit]
Oh! Wait, was the problem that only the new plugin version(s) caused an issue to begin with? If so, shouldn't we exclude ghc-typelits-natnormalise 0.9.1 specifically? Would that be enough for people not to construct a build plan that doesn't compile with -Werror and doesn't pass unit tests and doctests?
[/edit]

I have released version 0.9.3 of the natnormalise plugin, which requires no changes to any of our clash-* packages. See also c6f2ed3

I have released version 0.9.3 of the natnormalise plugin, which requires no changes to any of our clash-* packages.

That's great. Thanks.

I'd wait a bit more to also include the next ghc-typelits-extra release (due to the most recent features), and then this PR should be quite easy to land.

I have released a new version of ghc-typelits-extra with the new features, and it's compatible with ghc-typelits-natnormalise-0.9.3: https://hackage.haskell.org/package/ghc-typelits-extra-0.5.2

Tests have been run with the latest plugin versions here (18934e9):
https://gitlab.com/clash-lang/clash-compiler/-/pipelines/2193904911

There have been three separate comments discussing the need to exclude certain versions to not produce build plans that don't compile. These have not been addressed in any way. Could you please explain why, e.g., a compilation with ghc-typelits-natnormalise 0.9.1, is now suddenly okay when it wasn't before? Or if it isn't, what is preventing a user from constructing such a build plan? I have to admit I'm a bit peeved by the total lack of a response to these issues.

Could you give some guidance on how to actually compile with a modern ghc-typelits-natnormalise? I'm stuck on 0.7.12 when trying to compile with GHC 9.10.2 and 9.8.4.

[edit]
Ah, right, remove the clash-prelude-hedgehog package from cabal.project. Since CI does not do this, I really wonder whether it even tests with a modern version.
[/edit]

[edit 2]
So the proper fix is probably:

--- a/clash-prelude-hedgehog/clash-prelude-hedgehog.cabal
+++ b/clash-prelude-hedgehog/clash-prelude-hedgehog.cabal
@@ -49,7 +49,7 @@ library
     Clash.Hedgehog.Sized.Vector
 
   build-depends:
-    ghc-typelits-knownnat     >= 0.7.2   && < 0.8,
+    ghc-typelits-knownnat     >= 0.7.2   && < 0.9,
     ghc-typelits-natnormalise >= 0.7.2   && < 0.10,
     text                      >= 1.2.2   && < 2.2,

I get the sense that without that additional change, this PR is a no-op... did you verify that you could actually pick new versions of the dependencies whose version range you increased, or is it a no-op for you as well?
[/edit 2]

Here you can see that the build with ghc-typelits-extra-0.5.2 is succesfull: https://gitlab.com/clash-lang/clash-compiler/-/jobs/12307992383#L604

And you can see here that ghc-typelits-extra-0.5.2 depends on ghc-typelits-natnormalise-0.9.3: https://github.com/clash-lang/ghc-typelits-extra/blob/db8cfbd17a8c8984d28c8af254cc81860d8430a9/ghc-typelits-extra.cabal#L79

I will deprecate all versions of ghc-typelits-natnormalise between 0.7.12 and 0.9.3; so that ghc-typelits-natnormalise >= 0.8 means you pick at least version 0.9.3 in any build plan: https://hackage.haskell.org/package/ghc-typelits-natnormalise/preferred

I will deprecate all versions of ghc-typelits-natnormalise between 0.7.12 and 0.9.3

I guess that means we need to update index-state.

[edit]

Here you can see that the build with ghc-typelits-extra-0.5.2 is succesfull: https://gitlab.com/clash-lang/clash-compiler/-/jobs/12307992383#L604

Are you able to reproduce this locally? So far I've been unsuccesful.
[/edit]

Well, as you can see, that build had an updated cabal.project file with an allow newer on all the plugins: 18934e9#diff-b8ed06757045fac949c89f2139a862498ad2b6d1f82c61a31e7c91d6cf0eaa70R62-R67

Which yeah, does show that everything builds and passes tests, but did hide that we forgot to up the upper bound with clash-prelude-hedgehog

Since that means that the CI for this PR didn't actually test the changes in the PR, I'd say that needs to be addressed.

[edit]
In the future, probably a better way of testing this is instead of doing allow-newer, you just do:

constraints:
  ghc-typelits-extra ==0.5.2,
  ghc-typelits-knownnat ==0.8.2,
  ghc-typelits-natnormalise ==0.9.3,

so you verify that these packages are actually allowed, and you test with them. Of course, CI will still not cover all bases, such as the older allowed versions, so you will always need to stay alert and think your testing through.
[/edit]

[edit 2]
I completely scrolled past and missed #3061 (comment) initially :-). Or the GitHub web page didn't show it...
[/edit 2]

I'm sry that I missed the one bound in clash-prelude-hedgehog. I checked everything twice, but somehow it managed to hide from my eyes. I updated the file now, together with the index state.

Another question that still worries me: this PR marks to fix #3078, but the problem is only fixed with the latest version of ghc-typelits-extra. Thus, to really make sure a user won't run into the issue we also would need to increase the lower bound. Similar considerations will apply for #2784, which will require the latest version to work.

Hence, shall we already tighten the lower bounds as part of this PR?

Since #3078 is not a regression, I don't see a need to do that. It worked before, and it still works, it just works a lot better if you upgrade your plugin. But if somebody wants to keep it at the old version and keep stuff as it is, that's also fine, right?

For #2784 we will need to do something of course. It seems to make sense to bump the lower bound to the version that is needed for succesful compilation and operation; doing it conditionally seems like a major complication in the API. I'd not do that unless it really serves a purpose.